This patent includes a Microfiche Appendix which consists of a total of 5 microfiche that contain a total of 442 frames.
1. Field of the Invention
The present invention relates generally to verification languages, and more particularly to language statements which monitor and query the results of the application of test data.
2. Background of the Invention
To tackle the increasing complexity of integrated digital electronic circuits, designers need faster and more accurate methods for verifying the functionality and timing of such circuits, particularly in light of the need for ever-shrinking product development times.
The complexity of designing such circuits is often handled by expressing the design in a high-level hardware description language (HLHDL). The HLHDL description is then converted into an actual circuit through a process, well known to those of ordinary skill in the art as xe2x80x9csynthesis,xe2x80x9d involving translation and optimization. Typical examples of an HLHDL are IEEE Standard 1076-1993 VHDL and IEEE Standard 1364-1995 Verilog HDL, both of which are herein incorporated by reference.
An HLHDL description can be verified by simulating the HLHDL description itself, without translating the HLHDL to a lower-level description. This simulation is subjected to certain test data and the simulation""s responses are recorded or analyzed.
Verification of the HLHDL description is important since detecting a circuit problem early prevents the expenditure of valuable designer time on achieving an efficient circuit implementation for a design which, at a higher level, will not achieve its intended purpose. In addition, simulation of the design under test (DUT) can be accomplished much more quickly in an HLHDL than after the DUT has been translated into a lower-level, more circuit oriented, description.
The verification of HLHDL descriptions has been aided through the development of Hardware Verification Languages (or HVLs). Among other goals, HVLs are intended to provide programming constructs and capabilities which are more closely matched to the task of modeling the environment of an HLHDL design than are, for example, the HLHDL itself or software-oriented programming languages (such as C or C++). HVLs permit a DUT, particularly those DUTs expressed in an HLHDL, to be tested by stimulating certain inputs of the DUT and monitoring the resulting states of the DUT.
The ability of an HVL to monitor is key for such activities as determining whether the DUT is performing as expected, or for determining the extent to which the DUT has been tested.
The present invention adds to the HVL known as xe2x80x9cVeraxe2x80x9d capabilities which facilitate the monitoring of a DUT.
Vera is a language which supports a programming style known as Object-Oriented Programming (or OOP). It is a programming language in which classes, and hierarchies of classes, can be defined.
Within this OOP framework, the present invention provides a monitoring facility comprised of three main stages: i) Coverage Definitions, ii) Coverage Instantiation and Triggering and iii) Coverage Feedback.
A coverage definition is very similar to a class definition, within OOP, but does not contain methods or variables. Instead, the basic purpose of a coverage definition is to declare xe2x80x9cmonitor binsxe2x80x9d in terms of a state variable. Essentially, each monitor bin declaration has a unique bin name which is associated with a particular behavior of the state variable. This behavior can either be the state variable being in a particular state, or the state variable transitioning between a certain sequence of states. Whenever the state variable exhibits behavior that matches the particular behavior specified by a monitor bin declaration, that bin will increment a counter dedicated to that bin. If the option is so selected, the matching of a bin can also be recorded as a xe2x80x9cbin eventxe2x80x9d which comprises an indication of the bin that was matched and a time stamp as to when the matching occurred.
Instantiation of a coverage definition produces a coverage instance, which is pointed to by a handle. When instantiating a coverage definition, two key parameters are: an actual state variable that is to be monitored by the instance and a trigger expression which determines when the state variable of the instance is to be monitored. Instantiating a coverage definition, as part of a test program""s thread of control, means that a concurrent, non-terminating, xe2x80x9ccoverage instance processxe2x80x9d is also forked off. As long as at least one handle is pointing to the coverage instance, its coverage instance process will continue. When there are no longer any references to a coverage instance, the coverage instance, and its coverage instance process, are automatically deallocated (or xe2x80x9cgarbage collectedxe2x80x9d). Until it is deallocated, the coverage instance process will monitor, xe2x80x9cin the background,xe2x80x9d the value of the coverage instance""s state variable each time the coverage instance""s trigger expression is satisfied. Meanwhile, xe2x80x9cin the foreground,xe2x80x9d the thread of control which forked off the coverage instance process may continue to operate and can, for example, subject a DUT to stimuli. The DUT""s responses to such stimuli may be monitored by the coverage instance process. In particular, the coverage instance process will increment counters (or store bin events) indicating bins of its coverage instance which it determines have been matched by states of the specified state variable occurring at the trigger-expression-specified monitoring times.
The same foreground thread of control subjecting the DUT to stimuli can also determine the resulting state of the coverage instance""s monitor bin counters with a xe2x80x9cqueryxe2x80x9d function. Using the xe2x80x9cquery_xxe2x80x9d function, cross correlations between multiple coverage instances can be found. Thus the query and query_x functions make possible xe2x80x9cclosed loopxe2x80x9d testing since the same foreground thread of control can: i) instantiate a coverage instance that forks off an associated coverage instance process, ii) generate stimuli for a DUT which will cause the counters associated with the coverage instance""s monitor bins to be updated (or store bin events), iii) periodically query the contents of the coverage instance""s monitor bin counters (or bin events), and iv) alter the stimuli generated for the DUT based upon the results of the query.
Advantages of the invention will be set forth, in part, in the description that follows and, in part, will be understood by those skilled in the art from the description or may be learned by practice of the invention. The advantages of the invention will be realized and attained by means of the elements and combinations particularly pointed out in the appended claims and equivalents.